-
Notifications
You must be signed in to change notification settings - Fork 404
Build route from hop pubkey list. #1491
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Build route from hop pubkey list. #1491
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1491 +/- ##
==========================================
+ Coverage 90.95% 91.02% +0.07%
==========================================
Files 80 80
Lines 42724 43373 +649
Branches 42724 43373 +649
==========================================
+ Hits 38858 39482 +624
- Misses 3866 3891 +25
Continue to review full report at Codecov.
|
1842b5a
to
079405b
Compare
Rebased on #1490 to fix failing tests. |
Oops, lol, looks like it needs rebase already :( |
lightning/src/routing/router.rs
Outdated
/// Re-uses logic from `find_route`, so the restrictions described there also apply here. | ||
pub fn build_route_from_hops<L: Deref>( | ||
our_node_pubkey: &PublicKey, hops: &[PublicKey], route_params: &RouteParameters, network: &NetworkGraph, | ||
logger: L, random_seed_bytes: &[u8; 32]) -> Result<Route, LightningError> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lets skip the random seed? Its not like it is adding any randomization in this case - we can just use [0; 32]
, no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well technically I assume we could create MPP routes over different permutations of channels for the given hops? And in this having the randomization can't hurt?
Also, while I generally agree that requiring a [u8; 32]
of random bytes is not the most intuitive API which could be improved, I don't see why we shouldn't keep the signature of build_route_from_hops
not more or less consistent with the one of find_route
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well technically I assume we could create MPP routes over different permutations of channels for the given hops? And in this having the randomization can't hurt?
I...guess? I mean in practice nodes (except for LDK, sadly) ignore the SCID you provide it and just route over any available channel to the same peer, so it won't change behavior, only the route itself.
Also, while I generally agree that requiring a [u8; 32] of random bytes is not the most intuitive API which could be improved,
I think its probably the most practical, if not the most intuitive. Given the downstream issues we've seen with LDK -> user trait implementation reentrancy I want to lean even harder on the "avoid reentrancy to user code if at all possible" design goal going forward.
I don't see why we shouldn't keep the signature of build_route_from_hops not more or less consistent with the one of find_route?
Sure, it just seems like an extraneous parameter, if you strongly prefer it, so be it.
} | ||
} | ||
|
||
fn build_route_from_hops_internal<L: Deref>( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't quite understand why this is split into two functions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, this is kind of a remnant of my prior approach where I would implement much more functionality from scratch and therefore would add much more test cases for this implementation, for example in limits_total_cltv_delta
. This doesn't make too much sense now because get_route
is already covered, but I still kind of like the separation of the 'build route' and 'add shadow route' steps this allows. That said, I can build_route_from_hops
and build_route_from_hops_internal
, if you prefer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, no super strong opinion it just looked weird. Happy to leave it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it avoids a bunch of what would otherwise be confusing nesting (hint: there are places that could benefit from some method splitting)
c53a6c2
to
943b951
Compare
Rebased on main. |
943b951
to
f4924d9
Compare
Rebased again to fix tests. |
This basically LGTM, do you mind squashing down the fixup commits? |
f4924d9
to
f10303a
Compare
Done. |
@@ -5486,6 +5529,26 @@ mod tests { | |||
assert!(path_plausibility.iter().all(|x| *x)); | |||
} | |||
|
|||
#[test] | |||
fn builds_correct_path_from_hops() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps add a scenario where there are multiple channels between some or multiple pairs of hops, and that a certain path combination gets found with those distinct channels?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, let me clarify. The idea is not to test determinism, but rather that it is able to find multiple paths if there are multiple that match the given criteria.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd think the only case where we'd care about which specific subpaths are selected would be in MPP contexts, no? Like, in general I'd think the API here doesn't intend to suggest only a specific subpath would be selected?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Meta comment on commits: I think this can be a single commit, especially if DynamicPenaltyScorer
is removed. No need to separate out tests from implementation for something small-ish.
The commit message could be expanded to give the what and the why for posterity. Here's a good set of guidelines to follow: https://cbea.ms/git-commit/.
f6607a2
to
19ecb4c
Compare
lightning/src/routing/router.rs
Outdated
fn payment_path_successful(&mut self, _path: &[&RouteHop]) {} | ||
} | ||
|
||
let scorer = HopScorer { hops: &[&[*our_node_pubkey],hops].concat() }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not the prettiest, might have another look at this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't have a strong opinion, but note that we're trading cloning some iterators previously for allocating a Vec
here.
lightning/src/routing/router.rs
Outdated
fn payment_path_successful(&mut self, _path: &[&RouteHop]) {} | ||
} | ||
|
||
let scorer = HopScorer { hops: &[&[*our_node_pubkey],hops].concat() }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't have a strong opinion, but note that we're trading cloning some iterators previously for allocating a Vec
here.
19ecb4c
to
ba48ac8
Compare
ba48ac8
to
c88c71e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For commit messages, as per previously cited reference, please:
- don't end summary line with a period
- wrap body lines at 72 characters
Implements `build_route_from_hops`, which provides a simple way to build a route from us (payer) to the target node (payee) via the given hops (which should exclude the payer, but include the payee). This may be useful, e.g., for probing the chosen path.
c88c71e
to
2010670
Compare
This PR introduces a new function
build_route_from_hops
which allows to build a route just consisting of the given hops.It re-uses the logic from
find_route
/get_route
, but limits the graph discovery through usage of a custom scorer.